Today's corporate computing environments rely on distributed processing of computer applications for many reasons. By distributing the workload among different types of computers and different types of computer environments certain efficiencies may be achieved by “distributed applications.” However, distributed application processing is generally more complicated than writing a single application to execute locally on a single computer.
Some of the complexities of distributed processing systems include the need for a communication mechanism between the distributed portions of the distributed applications and maintenance of consistent, or at least compatible, versions of the distributed components. Communication solutions are available that may be implemented as part of an overall design architecture for a distributed computing system. Examples of how distributed computer components may communicate include remote procedure call (RPC), web services, and message queuing systems. Two examples of message queuing systems are Microsoft Message Queuing (MSMQ) available from Microsoft of Redmond, Wash. and IBM WebSphere MQ® available from International Business Machines (IBM) of Armonk, N.Y.
In either MSMQ or Websphere MQ “messages” are typically put onto a queue on one system and later retrieved from the queue on another system. The delay between send and receipt may be nearly instantaneous or may take time as determined by factors such as type of queue or queue priority. Messages on a queue typically include information to request an application (e.g., program) already installed on the receiving system to perform some task. Although messaging is typically used to communicate between different computer systems it is not only possible but reasonable in some cases to use a message queue for communication within a single computer system. As used herein, computer system refers to a logical embodiment of a computer. A logical embodiment of a computer is not limited to a physical machine and may include various forms of virtual machines. A virtual machine is a software implementation of a machine that executes programs like a physical machine (e.g., Logical Partition (LPAR) in a mainframe environment or implemented using virtualization software such as that available from VMware, Inc. of Palo Alto, Calif.)
Referring to FIG. 1, a high level diagram 100 of a message queue communication system is shown. Message queuing is a method of program-to-program communication. Programs such as program A 110 and program B 120 within a distributed application communicate by writing and retrieving application-specific data (messages) to/from queues such as queue 1 130 and queue 2 135, without having a private, dedicated, logical connection link between the programs. Messaging means that programs communicate with each other by sending data in messages and not by calling each other directly. Queuing means that programs communicate through queues. Programs communicating through queues need not be executing concurrently. In one example of a message queue implementation, an application such as program B 120 can define a named message queue and then register as a software routine that “listens” for messages placed onto the queue. Additional programs may connect to the same named queue and submit messages to the queue. The queue-manager software such as WebSphere MQ and MSMQ store and transport the message as necessary until a receiving application connects and calls the registered software routine. The receiving application can then process the message as appropriate. Also, in the example of FIG. 1, program A 110 and program B 120 can be executing in the same computer system or different computer systems.
With asynchronous messaging, the sending program proceeds with its own processing without waiting for a reply to its message. In contrast, synchronous messaging waits for the reply before it resumes processing. For the user, the underlying protocol is transparent. The user is typically concerned with conversational or data-entry type applications.
WebSphere MQ is used in a client/server or distributed environment. Programs belonging to an application can run in one workstation or in different machines on different platforms. Because of a consistent queuing mechanism (shown as MQ API 140), applications can be supported by different systems and the programs can be written in various programming languages.
Because WebSphere MQ communicates via queues (130, 135) it can be referred to as using indirect program-to-program communication. The programmer cannot specify the name of the target application to which a message is sent. However, the programmer can specify a target queue name; and each queue may be associated with a program. An application can have one or more “input” queues and may have several “output” queues containing information for other servers to process or for responses for the client that initiated the transaction.
In general, the programmer does not have to worry about the target program being busy, not available or not currently connected to a common network. The program sends messages to a queue that is associated with an application; and the applications may or may not be available at the time of the request. WebSphere MQ takes care of the transport to the target applications and may even “trigger” the target application if necessary.
If the target program is not available, the messages may stay in a queue and get processed later. The holding queue may be on the sending machine, the target machine or even possibly some machine in between and may be determined based on current network connectivity to the target machine. Also, applications can be running all the time or they can be triggered, that is, automatically started when a message arrives or after a specified number of messages have arrived.
Diagram 100 of FIG. 1 shows an example of how two programs, A 110 and B 120 may communicate with each other using message queues 130 and 135. Collectively, programs A 110 and B 120 and possibly other programs make up a business application. Queue 130 represents an output queue for program A 110 and an input queue for program B 120. Similarly, queue 135 provides communication from B 120 to A 110. Each connection from a program to a queue is passed through an application program interface (API) 140.
A message typically consists of two parts. A data part that is sent from one program to another and a message descriptor part (e.g., message header). The message descriptor identifies the message (message ID) and contains control information, also called attributes, such as message type, expiry time, correlation ID, priority, and the name of the queue for any reply message. Data is information to direct the receiving program how to perform a next step of the distributed application processing (e.g., program arguments and/or data structures).
In addition to providing a distributed communication mechanism as part of system architecture at program design time, another problem of distributed processing systems occurs at run-time and exists throughout the lifecycle of a distributed business application. This second problem is a requirement that different (i.e., distributed) systems be able to execute identical or at least compatible versions of the components of a distributed application. That is to say, if all computers are installed with version 1 of a distributed application, care must be used when upgrading to version 2 of the same distributed application. The problem of maintaining compatible versions is increased if a single component is used by more than one distributed application because multiple applications may be affected when upgrading a first application on the same system. This symptom in one operating environment is often referred to as “dll-hell”.
Because of these concerns and others, improvements to implementations of message queuing and techniques of maintaining consistent versions of distributed components may be desirable.